@nagisa do you want to merge this?

Should I remove the netbsd part until that is fixed upstream?

I'm thinking about what additional coverage testing these targets provides… There are the constants of course, but the list of different targets there is not really feasible to meaningfully cover and the coverage added by one or two targets is quite incremental. There's the conditional link attribute, but otherwise the "meat" of the bindings is consistent between all of the unixes…

And the cost of maintaining the CI for targets outside the default three available on GH has been quite significant in e.g. stacker/psm.

Is there anything else in particular you think testing on these targets could uncover?

Other than ensuring that it does work on those two targets and keeps working on them theres not much else to be had here.

The main benefit I see is that if you in the future change something that would break one of those targets you would see it pre-emtively.

I dont think coverage of your code is relevant anyways. Mostly a "does it work on platform X as I expected it to".

The effort to maintain ci testing for netbsd and freebsd for my software has been minimal. OpenBSD has always been the one that has been a pita to keep working, hence why I did not add it.